home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-mhsds-supmapping-03.txt < prev    next >
Text File  |  1993-07-08  |  11KB  |  414 lines
  1.  
  2.  
  3.  
  4. Network Working                                             S.E. Kille
  5. Group                                                 ISODE Consortium
  6. INTERNET-DRAFT                                               July 1993
  7.                                                 Expires:  January 1994
  8.  
  9.  
  10.  
  11.  
  12.  
  13.   Use of the Directory to support mapping between X.400 and RFC 822
  14.                               Addresses
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21. Status of this Memo
  22. This document is an Internet Draft.  Internet Drafts are working
  23. documents of the Internet Engineering Task Force (IETF), its Areas,
  24. and its Working Groups.  Note that other groups may also distribute
  25. working documents as Internet Drafts.
  26.  
  27. Internet Drafts are draft documents valid for a maximum of six months.
  28. Internet Drafts may be updated, replaced, or obsoleted by other
  29. documents at any time.  It is not appropriate to use Internet Drafts
  30. as reference material or to cite them other than as a ``working
  31. draft'' or ``work in progress.''
  32. Please check the I-D abstract listing contained in each Internet Draft
  33. directory to learn the current status of this or any other Internet
  34. Draft.
  35. Abstract
  36.  
  37. This document defines how to use directory to support the mapping
  38. between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].
  39. This draft document will be submitted to the RFC editor as a protocol
  40. standard.  Distribution of this memo is unlimited.  Please send
  41. comments to the author or to the discussion group
  42. <mhs-ds@mercury.udev.cdc.com>.
  43.  
  44.  
  45.  
  46.  
  47. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  48.  
  49.  
  50. 1  RFC 1327 Mappings
  51.  
  52. It is important to be able to represent RFC 1327 mappings in the
  53. directory [2].  The three RFC 1327 mappings are represented within the
  54. O/R Address and Domain hierarchies within the DIT [1, 3].
  55. The benefits of using the existing O/R address and domain trees are:
  56.  
  57.  
  58.  o  It is the ``natural'' location, and will also help to ensure
  59.     correct administrative authority for a mapping definition.
  60.  
  61.  o  The tree will usually be accessed for routing, and so it will be
  62.     efficient for addresses which are being routed.
  63.  
  64.        An alternative approach which is not taken is to locate the
  65.     information in separate subtrees, as defined in [3].  By
  66.     representing the information in separate subtrees, the mapping
  67.     information would be kept in a clearly defined area which can
  68.     be widely replicated in an efficient manner.  This is not
  69.     done, as the benefits of the approach proposed are greater.
  70.  
  71.  
  72. The values of the table mapping are defined by use of two new object
  73. classes, as specified in Figure 1.
  74.  
  75.  
  76. 2  Mapping from X.400 to RFC 822
  77.  
  78. As an example, consider the mapping from the O/R Address:
  79.  
  80.  
  81. PRMD=UK.AC; ADMD=Gold 400; C=GB
  82.  
  83. This would be keyed by the directory entry:
  84.  
  85.  
  86. PRMD=UK.AC, ADMD=Gold 400, C=GB
  87.  
  88. and return the mapping from the associatedDomain attribute, which
  89. gives the domain which this O/R address maps to.  This attribute is
  90. used to define authoritative mappings, which are placed in the open
  91. community tree.  The manager of an RFC 1327 mapping should make the
  92. appropriate entry.
  93.  
  94.  
  95. Kille                                  Expires:  January 1994   Page 1
  96.  
  97.  
  98.  
  99.  
  100. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  101.  
  102.  
  103.  
  104.  
  105. _______________________________________________________________________
  106. rFC822ToX400Mapping OBJECT-CLASS
  107.     SUBCLASS OF domain-component
  108.     MAY CONTAIN {
  109.         associatedORAddress,
  110.         nonAuthoritativeAssociatedORAddress,
  111.         associatedX400Gateway}
  112.     ::= oc-rfc822-to-x400-mapping
  113.  
  114. x400ToRFC822Mapping OBJECT-CLASS
  115.     SUBCLASS OF or-address-component                                10
  116.     MAY CONTAIN {
  117.         associatedDomain,
  118.         nonAuthoritativeAssociatedDomain}
  119.     ::= oc-x400-to-rfc822-mapping
  120.  
  121.  
  122. associatedORAddress ATTRIBUTE
  123.     SUBTYPE OF mhs-or-addresses
  124.     SINGLE VALUE
  125.     ::= at-associated-or-address                                    20
  126.  
  127. nonAuthoritativeAssociatedORAddress  ATTRIBUTE
  128.     SUBTYPE OF associatedORAddress
  129.     SINGLE VALUE
  130.     ::= at-non-authoritative-associated-or-address
  131.  
  132. associatedX400Gateway ATTRIBUTE
  133.     SUBTYPE OF mhs-or-addresses
  134.     MUTI VALUE
  135.     ::= at-associated-x400-gateway                                  30
  136.  
  137. nonAuthoritativeAssociatedDomain ATTRIBUTE
  138.     SUBTYPE OF associatedDomain
  139.     SINGLE VALUE
  140.     ::= at-non-authoritative-associated-domain
  141.  
  142. ___________Figure_1:__Object_Classes_for_RFC_1327_mappings_____________
  143.  
  144.  
  145.  
  146.  
  147.  
  148. Kille                                  Expires:  January 1994   Page 2
  149.  
  150.  
  151.  
  152.  
  153. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  154.  
  155.  
  156. To improve efficiency, the same information is made available in other
  157. places.  There are two cases:
  158.  
  159. 1.  Representation of mapping information in routing trees other than
  160.     the open community tree.
  161.  
  162. 2.  Representing a hierarchically derived mapping.  For example, a
  163.     mapping could be stored in the entry:
  164.  
  165.     MHS-O=Salford, PRMD=UK.AC, ADMD=Gold 400, C=GB
  166.  
  167.  
  168.     This information could be derived from information in the entry:
  169.  
  170.     PRMD=UK.AC, ADMD=Gold 400, C=GB
  171.  
  172.     However, it would take an extra lookup to find this information.
  173.  
  174. This information is stored by use of the
  175. nonAuthoritativeAssociatedDomain attributes.  For example, the entry
  176.  
  177.  
  178. MHS-O=UCL, PRMD=UK.AC, ADMD=Gold 400, C=GB
  179.  
  180. could have a nonAuthoritativeAssociatedDomain attribute of value
  181. ``UCL.AC.UK''. It is the responsibility of the manager of the entry to
  182. track changes in authoritative mappings, and to ensure that all such
  183. registed mappings are up to date.
  184.  
  185. Functionally, mapping takes place exactly according to RFC 1327.  The
  186. longest match is found by the following algorithm.
  187.  
  188. 1.  Take the O/R Address, and derive a directory name.  This will be
  189.     the O/R Address as far as the lowest OU.
  190.  
  191. 2.  Look up the entire name derived from the RFC 1327 key in a the
  192.     open routing tree.  The open tree must be used, to ensure
  193.     authoritative information.
  194.  
  195. 3.  Check for associatedDomain or nonAuthoritativeAssociatedDomain
  196.     attributes.
  197.  
  198.      o  If the mapped value is present, stop.
  199.  
  200.  
  201. Kille                                  Expires:  January 1994   Page 3
  202.  
  203.  
  204.  
  205.  
  206. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  207.  
  208.  
  209.      o  If not, strip one component of the name, and repeat.
  210.  
  211. If the non-authoritative information is provided, the mapping can
  212. always be achieved with two lookups.
  213.  
  214. Because of the availability of aliases, some of the table mappings may
  215. be simplified.  In addition, the directory can support mapping from
  216. addresses using the numeric country codes.
  217.  
  218. 3  Mapping from RFC 822 to X.400
  219.  
  220.  
  221. There is an analogous structure for mappings in the reverse direction.
  222. The domain hierarchy is represented in the DIT according to RFC 1279.
  223. The domain:
  224.  
  225. AC.UK
  226.  
  227.  
  228. Is represented in the DIT as:
  229.  
  230. DomainComponent=AC, DomainComponent=UK, O=Internet
  231.  
  232.  
  233. This has associated with it the attribute associatedORAddress, with a
  234. value:
  235.  
  236. PRMD=UK.AC; ADMD=Gold 400; C=GB
  237.  
  238.  
  239. There is an optimisation analogous to the reverse mapping provided by
  240. the nonAuthoritativeORAddress attribute.
  241. The ``table 3'' mapping defined in RFC 1327[2] is provided by the
  242. associatedX400Gateway attribute.  This value may be different in
  243. different routing trees, as this is not a globally unique mapping.  It
  244. is also possible to identify multiple possible associated gateways.
  245. This information is looked up at the same time as mapped O/R
  246. addresses.  In effect, this provides a fallback mapping, which is
  247. found if there is no equivalence mapping.  Functionally, mapping takes
  248. place exactly according to RFC 1327.  The longest match is found by
  249. the following algorithm.
  250.  
  251.  
  252.  
  253.  
  254. Kille                                  Expires:  January 1994   Page 4
  255.  
  256.  
  257.  
  258.  
  259. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  260.  
  261.  
  262. 1.  Derive a directory name from the domain part of the RFC 822
  263.     address.
  264.  
  265. 2.  Look up this name in the open routing tree to find the mapped
  266.     value (associatedORAddress or nonAuthoritativeAssociatedORAddress
  267.     or associatedX400Gateway.).  There should never be an attributes
  268.     of more than one of these types present.
  269.  
  270.      o  If one of the three mapped value types listed above is
  271.         present, stop.
  272.  
  273.      o  If not, strip one component of the name, and repeat.
  274.  
  275. If associatedORAddress or nonAuthoritativeAssociatedORAddress is
  276. found, this will define the mapped O/R Address.  If the
  277. non-authoritative information is provided, the mapping can always be
  278. achieved with two lookups.  If an associatedX400Gateway is present,
  279. the address in question will be encoded as a domain defined attribute,
  280. relative to the O/R Address defined by this attribute.  If multiple
  281. associatedX400Gateway attributes are found, the MTA may select the one
  282. it chooses to use.
  283.  
  284. Because of the availability of aliases, some of the table mappings may
  285. be simplified.  In addition, the directory can support mapping from
  286. addresses using the numeric country codes.
  287.  
  288.  
  289. References
  290.  
  291. [1] S.E. Kille. X.500 and domains.  Request for Comments RFC 1279,
  292.     Department of Computer Science, University College London,
  293.     November 1991.
  294.  
  295. [2] S.E. Kille. Mapping between X.400(1988) / ISO 10021 and RFC 822.
  296.     Request for Comments 1327, Department of Computer Science,
  297.     University College London, May 1992.
  298.  
  299. [3] S.E. Kille. Representing the O/R Address hierarchy in the
  300.     directory information tree, April 1992. Internet Draft.
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307. Kille                                  Expires:  January 1994   Page 5
  308.  
  309.  
  310.  
  311.  
  312. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  313.  
  314.  
  315. 4  Security Considerations
  316.  
  317. Security considerations are not discussed in this INTERNET--DRAFT .
  318.  
  319.  
  320. 5  Author's Address
  321.  
  322.     Steve Kille
  323.     ISODE Consortium
  324.     PO Box 505
  325.     London
  326.     SW11 1DX
  327.     England
  328.  
  329.  
  330.     Phone:  +44-71-223-4062
  331.  
  332.     EMail:  S.Kille@ISODE.COM
  333.  
  334.  
  335.     DN: CN=Steve Kille,
  336.     O=ISODE Consortium, C=GB
  337.  
  338.     UFN: S. Kille, ISODE Consortium, GB
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360. Kille                                  Expires:  January 1994   Page 6
  361.  
  362.  
  363.  
  364.  
  365. INTERNET--DRAFT        RFC 822/X.400 Mapping by X.500        July 1993
  366.  
  367.  
  368. A  Object Identifier Assignment
  369.  
  370.  
  371. _______________________________________________________________________
  372. mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
  373.           enterprises(1) isode-consortium (453) mhs-ds (7)}
  374.  
  375. mapping OBJECT IDENTIFIER ::= {mhs-ds 4}
  376.  
  377. oc OBJECT IDENTIFIER ::= {mapping 1}
  378. at OBJECT IDENTIFIER ::= {mapping 2}
  379.  
  380.  
  381. oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1}              10
  382. oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
  383.  
  384. at-associated-or-address OBJECT IDENTIFIER ::= {at 1}
  385. at-non-authoritatative-associated-or-address OBJECT IDENTIFIER ::= {at 2}
  386. at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
  387.  
  388. at-non-authoritative-associated-domain OBJECT IDENTIFIER ::= {at 5}
  389.  
  390.  
  391. _______________Figure_2:__Object_Identifier_Assignment_________________
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413. Kille                                  Expires:  January 1994   Page 7
  414.